In computer networks, presence information is used to indicate a user's ability and/or willingness to communicate with other users, typically expressed as a “status”. More precisely, however, presence information consists of an arbitrary number of elements, called presence tuples, where a tuple is a data object containing two or more components. Each presence tuple may consist of a status marker, an optional communication address, and an optional presence markup. Common presence status markers indicating the user's availability to communicate may include “online”, “offline”, “busy”, “away”, or “do not disturb”. Presence information may also include positional or geolocation information, such as the current Cartesian coordinates or global positioning system (GPS) coordinates of a presentity. An optional communication address may include both a communication means and a contact address for the user. According to RFC 2778, one type of communication means defined by the presence information model is instant message (IM) service and one type of contact address is an instant inbox instant messaging systems, such as AOL, ICQ, MSN, and Google. Other types of communication means and contact addressed for use in a presence tuple may include various forms of telephony and telephone numbers.
Presence information may be managed via a presence client operating on the user's computer. Presence clients may send presence information via a network connection to a presence service, which stores the presence information to make it available for distribution to other users. For example, a presence service may store presence information for multiple users in one or more presence information databases. Presence information databases may distribute presence information to users within the same presence network or across network boundaries to users associated with other presence services. It is appreciated that a single human user may be associated with multiple presence services. This may be accomplished, for example, by operating multiple presence clients where each presence client is associated with a different presence service or, alternatively, by operating a multi-service presence client. When a user belongs to multiple presence services, each presence service may independently maintain presence information for the user. Accordingly, synchronization of presence information across multiple presence services is not required (i.e., a user may be both “online” in AOL and “away” in MSN).
Presence service users may be divided into two categories. A first set of users, called presentities, provides presence information to the presence service so that it may be stored and distributed to other users. The other set of users, called watchers, receives presence information from the presence service for keeping track of the status of one or more watched presentities. A user may be both a presentity and a watcher, as is often the case when two users wish to be updated as to the presence status of each other.
A presentity is any entity described by presence information, and typically refers to the human user of a presence client. A presentity can also refer to a group of entities, such as a collection of customer service agents in a call center. A multi-user presentity such as this may be considered available if there is at least one agent ready to accept a call. A watcher is any user who receives presence information associated with a watched presentity. The presence service may maintain watcher information associated with the activities of watchers related to fetching or subscribing to presence information.
Presence information may be distributed between watchers and presentities using either a subscription/notification model or a query/response model. In the query/response model, presence information updates are requested by a watcher. For example, a watcher may request current presence information for a presentity. The presentity's response may include updated presence information or may indicate that no presence information has changed. If the watcher queries a presentity at regular time intervals, this may be referred to as polling.
In the subscription model, changes to presence information are distributed to subscribers via notifications. For example, a watcher may subscribe to a presentity for instructing the presentity to automatically provide presence information updates to the watcher via notifications. Any changes to the subscribed presentity's status are included in a notification message and sent to the watcher. The subscription/notification model therefore reduces the burden on the watcher to periodically request presence information updates. Additionally, the subscription/notification model eliminates the transmission of response messages indicating that no presence information has changed, which may unnecessarily waste resources.
Depending on whether the query/response or the subscription/notification model is used to obtain presence information updates, watchers may be divided into two categories, called fetchers and subscribers. A fetcher is associated with the query response/model and requests the current value of some presentity's presence information from the presence service. In contrast, a subscriber is associated with the subscription/notification model and requests notification from the presence service of future changes to a particular presentity's presence information.
One problem associated with conventional presence services is that typically, each network/network service provider maintains presence information only for subscribers in its own network. When a subscriber of network A requests presence information for a subscriber of network B, a presence server on network A must somehow determine the address of a presence server on network B, if one exists, and route the presence query appropriately. This requires the presence server on network A to determine and maintain routing information to a number of presence servers on different networks. In addition, the presence server on network A must also determine which network the out-of-network subscriber belongs to.
Another problem associated with conventional presence services is that there may be different levels of cooperation or agreement between different networks. For example, networks A and B may mutually agree to charge no fee or a minimum fee for presence messages that go from A to B or vice versa, while networks A and C may charge higher fees, or possibly even prohibit presence messages that span the two networks. Thus, each network's presence server must maintain information about whether to allow or deny traffic from particular networks, and how much to charge for traffic that is allowed.
Yet another problem associated with conventional presence services is that two networks may use incompatible presence protocols, or incompatible versions of the same presence protocol. In order to facilitate exchange of presence information between the networks, conversion from one protocol to another may be needed.
While the problems just described may be overcome, it is usually at additional cost to the network. For example, the presence servers may be required to maintain additional databases or include additional functions. Since each presence server must maintain the same information, this gives rise to potential problems caused when two presence servers, whether in the same network or in two different networks, are out of synchronization with each other.
Accordingly, in light of these difficulties, there exists a need for methods, systems, and computer readable media for providing presence information from a plurality of presence information providers.